Traditional methods of delivering software applications to users are inadequate to satisfy the needs and demands of today's enterprises and consumers. Delivery via tangible media (e.g., CDs and DVDs) is slow and inefficient, incurring significant production and distribution costs, occupying retail and warehouse shelf space, requiring substantial packaging, and consuming considerable time in delivery. Full-program downloads require inordinate amounts of time before a user may commence use. Server-based/thin-client computing does not provide a full PC user experience.
Software streaming provides advantages with reduced cost advantages of centralized streaming servers and local execution of programs that are delivered on-demand. Game developers may use streamed software to increase revenue and customer loyalty by offering titles worldwide over the Internet for purchase, rental or trial, all with anti-piracy protection and an optimum game-play experience. Software streaming also creates new revenue opportunities for software vendors, portals and ISPs who can use it to create software-on-demand and managed services.
Available software streaming systems and methods involve preprocessing that entails separating a program into small manageable packages that are stored on a server. The packages are downloaded as needed by the program being streamed. The client executes a program that helps manage the process by sending requests to a server for packages as they are needed.
Illustratively, U.S. Pat. No. 6,453,334, to Vinson, et al., describes a system for allowing only needed components of a remotely located target program to be executed on a local computer. Using the system described in Vinson, et al., only those portions of the program or data actually used are downloaded. Files of a program are broken into compressed, encrypted chunks in a preprocessing phase. This accomplished by opening the file, reading a block of chunk-size bytes, encrypting the block, compressing the block, calculating a unique file name for the block from the unique ID of the file and the block number, writing the just processed block to a new file in the specified directory of the runtime server using the file name previously generated, and then repeating for the next block in the input file until the end of file is reached. Thus, chunks are formed sequentially, one after another, comprising contiguous portions of the executable program. An index contains the information used by a client-side file system driver (FSD) to compute which chunk to download at runtime as it is needed. The FSD also creates a virtual drive, complete with drive letter, and places each target program that is to be accessed under a top-level directory on that virtual drive. Access to a chunk of a remote target program that has not been downloaded to the client machine may be granted or not depending on the type of access being requested (i.e. which volume or file function is being executed), an ID of a process attempting access, and optionally the path specified in the request for those requests containing paths.
While known software streaming systems and methods are useful for their intended purpose, namely managing the secure delivery of needed portions of a program, they still suffer shortcomings. There are many problems associated with streaming software that it would be advantageous to negate, work around, or reduce. For example, speeding up execution of streaming programs is an on-going issue. As another example, streaming to devices that occasionally lose a connection has not been satisfactorily addressed. As another example, it may be desirable to provide a user with an experience similar to that associated with an installed, as opposed to streamed, program. As another example, it may be desirable to provide streamed programs on consoles and mobile devices.
One key problem in particular relates to modern operating systems and security software which limit, impede or reject virtual drives and file system drivers. Such devices are perceived as security risks. Additionally, file system drivers must accommodate all I/O commands for all supported hardware. Not only is a substantial volume of hardware supported, but such drivers are frequently updated. Due to difficulties of making a substitute file system driver complete and maintaining the driver with all updates, such an approach is disfavored. Incompleteness and obsolescence of data contained in substitute file system drivers results in crashes.
Another key shortcoming of such systems and methods is an inability to prioritize delivery of components to expedite execution. Various instances may require different portions of a segmented program at different times. Existing systems do not optimize the creation of deliverable packages or facilitate the delivery of packages when needed.
What is needed is a system and method that allows streaming delivery of program components from a source such as a networked server or tangible medium without creating a virtual drive or file system driver. The invention is directed to overcoming one or more of the problems and solving one or more of the needs as set forth above.